ci: OSS-Fuzz build integration, run on CI via ClusterFuzzLite - #51

Adds the OSS-Fuzz build contract for the five Atheris harnesses already in
tests/fuzz/, and runs it on pull requests.

  .clusterfuzzlite/Dockerfile     base-builder-python + pinned requirements
  .clusterfuzzlite/build.sh       compiles every fuzz_*.py, zips its corpus
  .clusterfuzzlite/project.yaml   language, engine, sanitizers

On the upstream program itself: OSS-Fuzz's stated bar is that a project "must
have a significant user base and/or be critical to the global IT
infrastructure", which a self-hosted game control panel will not clear. That
is what ClusterFuzzLite is for — the same base images, the same build
contract, the same crash reporting, running on this repo's own CI with no
enrolment. If the project ever does qualify, these three files ARE the
submission: drop them in projects/linuxgsm-panel/ with a Dockerfile that
clones instead of copies.

Two things the OSS-Fuzz Python guide does not cover for a repo shaped like
this one:

- The panel is an application, not a pip package — there is no setup.py, so
  `pip3 install .` does not apply. The repo root goes on PYTHONPATH instead,
  which is both how the harnesses' imports resolve and how PyInstaller finds
  those modules to bundle.
- The harnesses pre-load paramiko / eventlet.tpool / config through
  importlib.import_module("..."), deliberately, so instrument_imports() only
  instruments the parser. A string is invisible to PyInstaller's static
  analysis, so those are named as --hidden-import; without them the targets
  build clean and die on first import. bad-build-check is left ON precisely
  because that is the failure mode here.

The workflow runs in code-change mode: it fuzzes what the diff touched, not
everything, and files a crash as SARIF in the Security tab next to the CodeQL
and Bandit alerts. run_fuzzers gets an explicit `language: python` — it
defaults to c++ and does not inherit the build step's setting.

This overlaps fuzz.yml on purpose: that is the broad every-target sweep, this
is the targeted one with real crash reporting. Dropping either is reasonable;
keeping both is what this does.

Batch fuzzing, corpus pruning and coverage are NOT enabled — all three need a
separate storage repo and a PAT to keep a corpus between runs. The README
says how to turn them on.

Verified: shellcheck clean, both YAML files parse, every corpus directory
resolves to a target. NOT verified locally — the Docker build itself; there
is no Docker on this machine. The README documents the helper.py commands to
check it, and CI is the first real run.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The first CI run failed, which is what it was there to do: bad_build_check
caught 3 of 5 targets dying at startup on

    ModuleNotFoundError: No module named 'eventlet.hubs.epolls'

eventlet.hubs picks its implementation with a string, at import time:

    builtin_hub_modules = tuple(importlib.import_module('eventlet.hubs.' + name)
                                for name in ('epolls', 'kqueue', 'poll', 'selects'))

so `--hidden-import eventlet.tpool` bundled tpool and none of the hubs it
transitively needs. Naming each hub by hand would work today and rot the next
time eventlet adds one, so this collects the whole package instead. Same for
paramiko (kex/cipher backends) and dns, which arrives transitively via
eventlet's greendns.

Kept the harnesses as they are rather than making their eventlet pre-load
optional: ssh_manager does tolerate eventlet being absent, but a fuzz target
whose import graph differs from production is testing something else.

Codacy's gate is zero new issues and it caught the one RUN line where $SRC
was unquoted. The COPY lines are not shell, so they are unaffected.